Hi @Tofandel, thank you so much for working on this!

The only thing I'm wondering about is whether or not this change may have a breaking impact on existing revisions.

I am currently blocking on the fact that block editors inside nested repeaters don't play well they seem to be saving as an array inside of blocks[blockName][] instead of block[]

As for breaking change, given that previously nested repeaters had no way to work (only nested blocks where working) I don't think there would be one, I'm not familiar with how revisions are created is it directly from the frontend field list and not the dirty attributes of the model?

Okay I completely rechanged the approach, I got everything working perfectly finally, schema is clean and a bit less memory hungry than before

I also tested old revisions and switching backend while editing frontend since the structure is mostly the same and it's all backwards compatible, I made sure of it

Good to go now repeaters are only stored like

parts
blocks-parts-1|lessons
blocks-lessons-1|content

Instead of the original approach of

parts
parts|blocks-parts-1|lessons
parts|blocks-parts-1|lessons|blocks-lessons-1|content

Or the current not working approach in 3.x

parts
blocks-parts-1-lessons
blocks-parts-1-blocks-lessons-1-content

This is the same as how blocks are stored flattened and it seems to work just fine so I just thought let's reuse that

I think I'm pretty much done on the best way to approach this by causing the least amount of breaking change

Now the schema hasn't even changed except for the nested repeaters outside the block editor as mentionned in the previous comment which was something that was not working before so it can hardly be called a breaking change and only a fix

As for testing, I'm personnaly testing on a module with 4 levels of inline repeaters with blocks and nested blocks and browsers inside those repeaters and repeaters inside those blocks and I'm happy to report that everything is working perfectly

This is great @Tofandel , thank you!